fix(objectql): the security-catalog name-conflict refusals say a permission set holds one name per namespace - #33463

Requested by Elon · project thread
Fixes #33389

Clause-②: no
Metadata-protocol: none

维护者速读

• 改了什么:SecurityCatalogNameConflictError 的两段报错文字(热安装与冷启动)不再说「岗位、权限集、能力每个部署一个名字」,改成「岗位和能力每个部署一个名字,权限集每个命名空间一个持有者」,并列出仍只有一个持有者的情形;措辞与 docs(spec): the permission set name describe and the permission sets page say one holder per namespace #33384 落地的 describe 一致。
• 为什么改:feat(core, objectql, metadata, metadata-protocol, plugin-security): a permission-set name is held once per namespace, judged by one predicate (ADR-0150 child B) #32742 之后权限集按 (包, 名字) 识别,两个不同命名空间的包可以各持有同名权限集,旧句子从那时起就是错的;拒绝本身一直只在 permissionSetHoldersMeet 判定相遇时触发,没有错。
• 风险与回滚:只改报错文字和一段代码注释,不动规则、错误码(NAMESPACE_CONFLICT)或状态码(422);@objectstack/objectql patch changeset。回滚即 revert。
• 先看:packages/objectql/src/registry.ts 新增的 SECURITY_CATALOG_NAME_RULE 常量,以及它在 coldBootConflictMessage 与 SecurityCatalogNameConflictError 构造函数里的两处引用。
• 两分钟验证:grep -n "A permission set holds one name per" packages/objectql/src/registry.ts,预期恰命中常量一行;grep -n "Positions, permission sets and capabilities each" packages/objectql/src/registry.ts 预期零命中。
• 需要你做的:无,席位落地。

What changes

• packages/objectql/src/registry.ts:
  • New module constant SECURITY_CATALOG_NAME_RULE, the one rule sentence both wordings of SecurityCatalogNameConflictError state: "Positions and capabilities each hold one name per deployment. A permission set holds one name per namespace: packages of two namespaces may each hold a set of one name, while two packages of one namespace, a package with no namespace, a platform package (base, system, sys), the environment and the platform-requested guest_portal share one set of it." This is the holder list of the permission set name describe that docs(spec): the permission set name describe and the permission sets page say one holder per namespace #33384 landed (packages/spec/src/security/permission.zod.ts), in the same words.
  • coldBootConflictMessage (the cold-boot refusal): FROM "Positions, permission sets and capabilities each hold one name per deployment: an assignment names a position or a permission set by its bare name, so with two holders the environment's stored item would be served in place of the package's definition." TO the rule sentence, then "Under that rule the environment's item and the package's share one definition of the name, so with two holders the environment's stored item would be served in place of the package's definition."
  • The hot-install message in the SecurityCatalogNameConflictError constructor: FROM "Positions, permission sets and capabilities each hold one name per deployment: an assignment names a position or a permission set by its bare name, with no package to tell two definitions apart, so with two holders which definition grants would depend on registration order." TO the rule sentence, then "Under that rule PACKAGE and each holder named here share one definition of the name, with nothing to tell two definitions of it apart, so with two holders which definition grants would depend on registration order."
  • The comment in SchemaRegistry.registerItem that explains why the three security catalog types are refused ("an assignment names a position or a permission set with no package context") now says a position or a capability is named with no package context and a permission set's name has one holder per namespace (ADR-0150 D2/D9, permissionSetHoldersMeet).
• .changeset/33389-security-catalog-conflict-text.md: @objectstack/objectql patch.

No rule changes. The doors, permissionSetHoldersMeet and the envelope (NAMESPACE_CONFLICT, 422) are untouched; the head and the remedy of each message are unchanged.

Tests

No test pinned the old sentence: git grep on 0c2aeb9643 for "Positions, permission sets and capabilities", "assignment names a", "no package to tell" and "served in place of the package" found only registry.ts itself, a docs page, an ADR, a migration entry and comments (listed under Acceptance notes); no assertion in objectql, runtime, plugin-security, cloud-connection, metadata-protocol or dogfood reads either sentence. No new pin is added: the refusal prose has no consumer that parses it, and the existing suites already assert the envelope (code and status) and the holders. Local readings at 2a6c935f7e, under os-verify-lock:

• objectql build closure, then vitest run on registry-security-catalog-namespace, protocol-permission-set-name-registry-reading, registry-security-catalog-names-held-by, manifest-service-residual-security-seal and environment-overlay-five-types: 5 files, 103 tests passed. objectql typecheck, including check:test-typecheck: OK.
• protocol-boot-hydration-scoped, package-scoped-exact-qualifier and registry-namespace-install-gate: 3 files, 314 tests passed.
• eslint --no-inline-config on registry.ts: exit 0.

Acceptance notes

Other places that say a permission set holds one name per deployment, read on 0c2aeb9643 and left alone, each for the reason given:

• packages/metadata-protocol/src/protocol-save-door-refusals.ts (the save door's Security catalog name conflict refusal): already says "A permission set holds one name per namespace" with the same holder list. Nothing to change.
• packages/spec/src/migrations/entries/semantic/18.security-catalog-environment-overlay-refused.ts (reason: "Positions, permission sets and capabilities hold one name per deployment"): an ADR-0087 migration entry describing a v18 change, in packages/spec, outside this lane. docs(spec): the permission set name describe and the permission sets page say one holder per namespace #33384 raised it as an open question.
• packages/spec/src/kernel/customization-package.ts:252 (the adr_0146_d6_security_catalog basis): describes ADR-0146 D6 as written.
• packages/objectql/src/security-catalog-namespace.ts module header: its first section states the original rule and its own "The narrowing: a permission set is one name per namespace" section already states the ADR-0150 narrowing.
• Test comments, not assertions: packages/objectql/src/protocol-boot-hydration-scoped.test.ts:217, packages/qa/dogfood/test/showcase-security.ts:32, packages/qa/dogfood/test/showcase-d7-default-profile.dogfood.test.ts:65.
• content/docs/permissions/delegated-administration.mdx:69 ("an assignment names a position or set, and the gate resolves the name in the security catalog"): a description of the delegated-admin gate, not of the holder rule.
• Decision records (ADR-0048 addendum, ADR-0131, ADR-0146 D6): not touched.

Verification

Derived gates at 2a6c935f7e: dispatch-gates --commands gave 65 families. 64 exited 0. check:dual-build-cjs-loads exited 3, a prerequisite not met because only the objectql closure was built, so it is NOT MEASURED; CI Build Core covers it. dispatch-gates --ran reconciles 65 of 65. The CI check-runs on this pull are the authority for every gate family.

Generated by Claude Code